Subject: An Alternate Approach to SNA over IP

From: "Shannon Nix" <[email-masked]>
Date: Wed, 22 Sep 93 11:33:48 EST

Hello,

When we at Netlink began thinking about SNA over IP a couple years ago,
we were favoring a different approach from the one this group has undertaken.  

The key difference is:

With DLSW, IBM has chosen to multiplex SNA data links over one or more 
reliable TCP connections.  While we considered this approach, we were favoring 
encapsulating LLC-2 sessions inside of IP datagrams.

Recent consideration some of our DLSW discussion topics:

1) SCALABILITY
2) FLOW-CONTROL

has caused me to reconsider our original design in a more favorable light.

I realize this may not be a great time to propose a fundamental change
in design.  However, it does seem to address a lot of the key issues that
the SIG has been wrestling with.

I will outline (briefly) the scheme below and discuss its pros and cons:

SYSTEM ARCHITECTURE:

+------------------------------------------+
|            DATA LINK PASSTHRU            |
+------------------------------------------+
----- NORMALIZED DATA LINK INTERFACE ------
+------++------++--------------------------+
| SDLC || QLLC ||           LLC-2          |
+------++------++--------------------------+
                +-------++-------++--------+
                | 802.5 || 802.3 || IPSEQ  |
                +-------++-------++--------+
                                  +--------+
                                  |   IP   |
                                  +--------+
                                  
NOTE : The NORMALIZED DATA LINK INTERFACE implies that all DLCs
       present a generic ABM-like appearance.
                                  
NOTE : The DATA LINK PASSTHRU component consists of a state machine
       that "ties together" data link events from any two normalized
       data links and gives them the appearance of a single data link.
       
       This state machine would not be terribly dissimilar from 
       the one in RFC 1434.
                                  
NOTE : The IPSEQ insures that IP frames are delivered in sequence
       between peer LLC-2 stacks.  This might even be UDP???.
       
FRAME FORMAT:

+--------+-----------+---------------+----------------------------+       
| IP HDR | IPSEQ HDR | 802.5 MAC HDR | LLC HDR | DATA             |
+--------+-----------+---------------+----------------------------+       
       
ROUTE EXPLORATION:

1.       CANUREACH will now be triggerred by a broadcast TEST emmitted
         by the MAC service user, the LLC stack.  It could be implemented 
         by using IP multicast.  The multicast group address and the virtual 
         LAN number (for SRB) would be commonly administered throughout a 
         DLSW network.
         
2. While ICANREACHs could be directed to the originator, it might
        be advantageous to multicast those as well.  This would allow other
        stations to "learn".
       
ADVANTAGES OF LLC over IP:

1.  SCALABLE!!.  LLC-2 stacks should be designed to support many stations
    on a LAN.  Since we all have such a stack lets use them!
    
2.  RESOURCE DEFINITION.  Route Exploration is implemented in the same 
    fashion as LAN explorations.  The broadcast is simulated by using
    a multicast address.  In this fashion DLSW do not have to be defined
    to one another.  The only requirement is the administration of the
    multicast group to which the DLSW belongs.
    
3.  ROUTE-DISCOVERY.  Route Resolution (ICANREACH) Data may be multicast 
    rather than directed to allow other DLSW nodes to "learn" IP-MAC 
    correlations.
    
4.  FLOW CONTROL.  LLC-2 stacks have sufficient backpressure mechanisms:
    sliding window, RNR,....  Lets use them!.
    
5.  FRAME SIZE.  IP+ IPSEQ + MAC + LLC + DATA <  IP + TCP + SSP + DATA
               ( X +   2   + 18  +  4  +  Y ) < ( X + 20  + 16  +  Y )
                                   24 + (X+Y) < 36 + (X+Y)
                                   
    A third less filling!                                   
                                   
6.  EASE OF IMPLEMENTATION.  No need to implement convert packets into
    a stream and back again.
    
    Tastes great!
    
7.  END-TO-END LF - Since this is already carried in the RIF let's use it.

8.  END-TO-END RIF - ??? as an option???

DISADVANTAGES (?):

1.  SUPERVISORY TRAFFIC:  S-FRAMES will also travel on the backbone.
    However, I'm not sure a properly tuned LLC endpoint will generate much
    more overhead ( if not less) than the combination of:
      1)  TCP's control mechanisms
      2)  A DLSW pacing mechanism - for flow control
      3)  A Keep-alive mechanism if we choose to have this function

    Also the frame size savings on productive traffic will help to counter-
    balance this as well.

Sorry if I've rocked the boat,
Shannon

(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)(*)   Shannon Nix    (*)(*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)      Netlink, Inc.     (*)(*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  3214 Spring Forest Rd.   (*)(*)(*)(*)(*)(*)(*)
(*)(*)(*)(*)(*)(*)(*)  Raleigh N.C. 27604 USA   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Phone:  (919)-878-8612   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)  Fax:    (919)-872-2132   (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*) Internet: [email-masked] (*)(*)(*)(*)(*)(*)(*) 
(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)(*)
    
--- End Included Message ---

---

From: "Shannon Nix" <[email-masked]>
Date: Wed, 22 Sep 93 14:44:50 EST

On Wed, 22 Sep 93 16:49 GMT, Robin Layland wrote:

> 
>Quick Reply to Shannon proposal:
> 
> 
>1. Thee is a big problem with assume that people can having properly tuned LLC
>endpoint. That requires changing every end-station plus it needs to be done at
>once since LLC2 pacing doesn't exchange values. Get properly tuned LLC 2 is very
>hard in any size network from my experience (I tried).

I am not proposing that we change LLC values in end-systems. We still have
data link termination here!  There are still three seperate DLC sessions:

     anyDLC           LLC/IP             anyDLC
ES<----------->DLSW<------------->DLSW<---------->ES

The LLC parameters which have to be tuned are those between DLSWs.
The routers have LLC sessions with other routers as well as LLC sessions
with the end-systems.  The LLC sessions between routers are subject to 
timeout problems but these can be negotiated/adjusted dynamically.

> 
>2. This doesn't solve the LLC2 time out problem. Again, with properly set values
>there is no problem (see #1)

See response to #1.

> 
>3.This doesn't solve the problem of SDLC to LLC2. Someone must convert.
> 

See response to #1:

     SDLC             LLC/IP             LLC2 (or QLLC, or SDLC....)
ES<----------->DLSW<------------->DLSW<---------->ES

>4. The LLC flow control is end-to-end. How does the intermediate (router)
>station slow things know and ensure fairness.
> 

  There are three seperate sessions on which to exert flow control:
    1) ES-A     to ROUTER-A
    2) ROUTER-A to ROUTER-B
    3) ROUTER-B to ES-B

  Routers issue RNRs in either direction using the native LLC mechanism!

> 
>Some more at the next meeting.
> 
>Robin Layland

See you next week, 
Shannon

---

From: "Shannon Nix" <[email-masked]>
Date: Wed, 22 Sep 93 15:26:47 EST

On Wed, 22 Sep 93 11:08:24 PDT, Alan K. Bartky, Manager of Technology wrote:

>Shannon - 
>
>A couple of comments
>
>One of the problems that DLSw/SSP is supposed to solve
>is the fact that IP networks can't always guarantee LLC RR response time
>in bridging environments due to things like no priority, IP bursts, etc.
>If nothing else you would have to address this.
>
>DLSw is supposed to guarantee this to not happen by breaking up
>an end to end LLC connection used in bridging into an LLC to Router
>connection, a Router to Router connection using SSP, and then another
>LLC to end station connection.

Alan,

It seems clear from yours and other's replies that I have miscommunicated my
proposal.

First:  What I am not NOT suggesting is end-to-end LLC2 with IP tunnelling!!

What I have suggested IS still Data Link Switching.  I fully appreciate the 
value of terminating the boundary data links and having a reliable router-
to-router connection in the middle.

This group has expressed a desire to make that ROUTER-TO-ROUTER 
connection TCP-independent. In otherwords make DLSW transport independent.  
What I AM suggesting is that LLC2 over IP is a more suitable transport and 
easier to implement.

I submit that a number of the issues we have been addressing are TCP issues
and not Data Link Switching issues:

It is already generally accepted that there are real scalability problems
with TCP.  There is an "awkwardness" about sending packets through
a stream oriented transport.  We are reinventing complex flow control 
mechanisms. And the list goes on...

I am simply proposing what I feel is a less awkward transport for DLSW.
>
>Running LLC over IP is an interesting idea but I don't think...
>DLSw is more of a protocol that is appropriate to routers, it is one that
>is implemented by IBM and it is the main focus of the group.  You yourself
>indicated the importance of interoperability with current 6611s in
>your contributions.  It is important we keep working with DLSw in
>documenting how it works and add the features as specified in the working
>groups.
>

I am not abandoning DLSW nor interoperability with the 6611.  I simply think
LLC2 over IP is a more suitable transport than TCP.

I have in mind a model for interoperability with the 6611:

 +------------------------------------------------+
 | DATA LINK SWITCHING (TRANSPORT INDEPENDENT)    |
 +------------------------------------------------+
 ----------- NORMALIZED DLC INTERFACE -------------
 +------++------++--------------------++----------+
 + SDLC || QLLC ||         LLC-2      ||   SSP    |
 +------++------++--------------------++----------+
                 +--------++----------++----------+
                 |  802.x ||   IPSEQ  ||   TCP    |
                 +--------++----------++----------+
                           +----------------------+
                           |         IP           |
                           +----------------------+

Whew...I wish I had an interactive whiteboard!!

>I think that alternatives to DLSw could be discussed in a different group
>than the DLSw SIG.  I certainly think the McData approach (or others)
>should discussed as alternatives when only simple conversion is desired,
>but not in the DLSw SIG.

   This, however, is simply an alternate transport.  One that I feel has
   a lot of advantages.  As such, it seemed quite appropriate to propose
   it within the DLSw SIG.
>Regards,
>Alan K. Bartky

Rgds, Shannon

---

From: Robin Layland <[email-masked]>
Date: Wed, 22 Sep 93 21:27 GMT

Comments on Shannon's reply to what I wrote on his proposal to use LLC2 instead
of TCP/IP.
 
> 
> There are still three seperate DLC sessions:

>timeout problems but these can be negotiated/adjusted dynamically.
 
This does not answe the flow control problems. The main question is still how to
map many sessions to the LLC2 session between the routers and perform flow
control. When do you issues an RNR back to the end-station and still guarantee
fairness between session. This is the hard task of flow control. The second
issues on flow control is how to perform something between than a fixed (or
sliding) windowing algorithm. (but this is the lesser one).
 
I don't understand how this will simplify the other groups work. You still need
the Connect groups work on the end-station to router flows, the capabilities
group on what each DLSw machine can do and the Loop preventation work for
dealing with Spanning Tree. Yes the header is less the TCP/IP but this seems to
be the main difference.
 
I do not see how this solves the scalability issues. You would need an LLC2
session instead of an TCP session between each DLSw router. (sure its only one
session instead of two but we have two only because of the way IBM implemented
it). 
Some of the scalability issues concerned finding the location of names, still a
problem if you use LLC2 instead of TCP.
 
Robin Layland